Thank you for the comprehensive implementation.
Before merging, please address two points:

1. When both the NTFS and exFAT kernel driver preferences are enabled, VeraCrypt executes blkid -p twice for the same device, once in each resolver. Since each call has a timeout of two seconds, this can noticeably delay mounting on slow or damaged devices. Please detect the filesystem once and share the result, ideally through a single Linux kernel mount resolver used by both mount paths.

2. The availability check accepts any filesystem registered as exfat. This includes the older Linux 5.4 staging implementation and potentially vendor implementations or implementations maintained outside the kernel tree, while the pull request rationale refers to the modern driver introduced in Linux 5.7. Please either restrict the selection appropriately or explicitly document and test that accepting any registered or loadable kernel exFAT implementation is intentional.

Please also test the case where no driver is available, the case where module loading is blocked by system policy, both the native device mapper path and the nokernelcrypto path, both kernel driver preferences enabled together, and a volume that does not contain exFAT. The documentation should use the precise name of the exFAT FUSE mount helper and avoid the currently unverified suspend and hibernate claim.

Thanks for the review. Pushed a fixup for both points:

1. Merged the NTFS and exFAT resolvers into one ResolveKernelMountOptions, so blkid -p runs at most once per mount, shared between both checks (NTFS still takes precedence).
2. SelectExfatKernelFilesystemType now requires kernel 5.7+ (when fs/exfat left staging) before accepting a registered exfat type.

Also fixed the docs to name the actual helper (mount.exfat-fuse) and dropped the unverified suspend/hibernate claim for exFAT, had just duped the NTFS template for that (hadn't actually verified it, just followed the same unverified-benefit pattern as the NTFS entry).

Tested end-to-end on openSUSE Tumbleweed, kernel 7.1.2, with a real built binary and a real exFAT-formatted volume:

• Default mount: native device-mapper path, fuseblk on /dev/mapper/veracrypt1 (unchanged baseline behavior).
• --filesystem=kernel-exfat and -m kernelexfat (autodetect): both mount as real kernel exfat on the native device-mapper device.
• -m nokernelcrypto,kernelexfat: correctly routes through the FUSE/loop aux path (/dev/loop0) instead of device-mapper, still resolves to kernel exfat. I would argue this confirms both call sites of the merged resolver work.
• -m kernelntfs,kernelexfat together, strace -f -e trace=execve on the whole mount: exactly one blkid call, followed by mount -i -t exfat ... /dev/mapper/veracrypt1.
• Module-blocked-by-policy: temporary modprobe.d block made exfat loading fail cleanly into the driver-unavailable path.
• Confirmed mount.exfat is really symlinked to mount.exfat-fuse on this box.